Data service method and device in vessel data integration system

ABSTRACT

The present invention relates to a vessel data integration system and a vessel comprising same. According to the present invention, a vessel data request including a VDM path is received, and by using the received VDM path, the requested vessel data is searched from a database in which vessel data are stored. The VDM path may be an identifier hierarchically defining paths leading to each vessel data in a VDM, and each vessel data may be identified by the VDM path. Accordingly, necessary vessel data may be efficiently provided to various third-party services.

TECHNICAL FIELD

The present disclosure relates to a vessel data integration system and avessel comprising the same.

BACKGROUND ART

Vessels are categorized according to the purpose of use, the type ofcargo and the method by which the cargo is loaded, and vessels may beclassified into commercial vessels, specialized vessels, militaryvessels and fishing vessels according to the purpose of use, and may beclassified into container ships, bulk carriers, tankers, chemicaltankers, LPG carriers, LNG carriers and car carriers according to thetype of cargo.

Various types of vessels as described above each have a great deal ofsensors and devices mounted thereon to function for use that suits thepurpose.

Each sensor and device are collected and processed by integrationequipment and provided to a service necessary for safe navigation, andbecause one or more sensors and devices are made using differentprotocols for each manufacturer, it was not easy to collect data, andeven though data is collected, there is no method for managing thecollected data in an integrated manner, so there are many constraints ontransfer and utilization of the collected data not only on board butalso on shore.

Meanwhile, International Maritime Organization (IMO) compels thespecified “Maritime navigation and radiocommunication equipment andsystems” (e.g., Voyage Data Recorder (VDR), Integrated Navigation System(INS), etc.) to conform to IEC 61162 based digital interfaces. Here,International Electronical Committee (IEC) 61162 is the communicationstandards for communication interfaces between “Maritime navigation andradiocommunication equipment and systems”, and IEC 61162 is aligned withthe National Marine Electronics Association (NMEA) standard.

In contrast, equipment (e.g., Alarm Monitoring System (AMS), BridgeManeuvering System (BMS), etc.) other than “Maritime navigation andradiocommunication equipment and systems” is not bound to conform to IEC61162. Additionally, there is a great limitation in expressing datausing the already published NMEA, and thus other industrial standards ora de facto standard is mainly selected and used.

By this reason, there is no common standard for interfacing betweenequipment other than “Maritime navigation and radiocommunicationequipment and systems”.

For example, the NMEA sentence structure receiving the position fromGlobal Positioning System (GPS) is as shown in FIG. 1. The NMEA sentenceis shared between system developers through a standard document, but anyindividual modification is not allowed.

When data to be used on the IEC 61162 standards is not data that ispredefined in NMEA sentence, is it is necessary to additionally performa task for defining the corresponding data in NMEA sentence under themutual agreement, and share through an interface agreement documentbetween them.

As described above, when data to be used on the IEC 61162 standards isnot predefined in NMEA sentence, there is inconvenience in having toadditionally define the data, write it in a document and share it.

Technical Problem

The present disclosure is designed to solve the above-described problem,and therefore the present disclosure is directed to providing a vesseldata integration system for efficiently providing necessary vessel datato various third-party services based on a Vessel Data Model (VDM) thatcan manage vessel data in different formats made by different protocolsinto an integrated data format, and a vessel comprising the same.

SUMMARY OF THE INVENTION

To achieve the above-described object, a data service method in a vesseldata integration system according to an embodiment of the presentdisclosure includes receiving a vessel data request including a VesselData Model Path (VDM Path) from a service requester, and searching forthe requested vessel data from a database in which vessel data isstored, based on the VDM Path.

In the data service method in the vessel data integration systemaccording to an embodiment of the present disclosure, the VDM Path mayhierarchically define paths leading to each vessel data on a Vessel DataModel (VDM), and each vessel data may be identified by the VDM Path.

In the data service method in the vessel data integration systemaccording to an embodiment of the present disclosure, a data range inwhich to perform the search may hierarchically change depending onhierarchy level of the VDM Path.

The data service method in the vessel data integration system accordingto an embodiment of the present disclosure may further includeidentifying if the service requester has an access authority for a datarange specified by the VDM Path, and as a result of the identification,when the service requester has the access authority, may perform thesearch.

In the data service method in the vessel data integration systemaccording to an embodiment of the present disclosure, the VDM mayinclude a vessel model, a system model and a data model. In this case,the vessel model may define hierarchical structure in an order ofvessel, equipment group, equipment and component, the system model maydefine hierarchical structure in an order of system, logical device andlogical node for collecting vessel data, and the data model may definehierarchical structure in an order of data object about structure ofvessel data and data attribute about attribute of vessel data.

In the data service method in the vessel data integration systemaccording to an embodiment of the present disclosure, the VDM Path mayinclude at least one name of equipment group, equipment, component,logical device, logical node, data object and data attribute.

In the data service method in the vessel data integration systemaccording to an embodiment of the present disclosure, the VDM Path mayhave a sequential arrangement of at least one name of equipment group,equipment, component, logical device, logical node, data object and dataattribute.

The data service method in the vessel data integration system accordingto an embodiment of the present disclosure may further include providingthe found vessel data to the service requester in response to the vesseldata request.

In the data service method in the vessel data integration systemaccording to an embodiment of the present disclosure, the searching mayinclude, in case of the vessel data request using a Query ApplicationProgramming Interface (API), extracting the requested vessel data by aPull method, and in case of the vessel data request using a Push API,receiving the requested vessel data by a Push method.

Meanwhile, a data service device in a vessel data integration systemaccording to an embodiment of the present disclosure includes acommunication unit to receive a vessel data request including a VesselData Model Path (VDM Path) from a service requester, and a search unitto search for the requested vessel data from a database in which vesseldata is stored, based on the VDM Path.

In the data service device in the vessel data integration systemaccording to an embodiment of the present disclosure, the VDM Path mayhierarchically define paths leading to each vessel data on a Vessel DataModel (VDM), and each vessel data may be identified by the VDM Path.

In the data service device in the vessel data integration systemaccording to an embodiment of the present disclosure, the search unitmay hierarchically change a data range in which to perform the search,depending on hierarchy level of the VDM Path.

The data service device in the vessel data integration system accordingto an embodiment of the present disclosure may further include anidentification unit to identify if the service requester has an accessauthority for a data range specified by the VDM Path, and as a result ofthe identification by the identification unit, when the servicerequester has the access authority, may perform the searching operationby the search unit.

Advantageous Effects

According to the vessel data integration system of the presentdisclosure and the vessel comprising the same, necessary vessel data maybe efficiently provided to various third-party services.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an exemplary diagram showing the conventional NMEA sentencestructure.

FIG. 2 is a schematic diagram showing the structure system of VDMapplied to the present disclosure.

FIG. 3 is a schematic diagram showing the configuration of a smart shipwith a vessel data integration platform according to an embodiment ofthe present disclosure.

FIG. 4 is a schematic diagram showing the main functions of a vesseldata integration platform according to an embodiment of the presentdisclosure.

FIG. 5 is a schematic diagram showing the configuration of a vessel dataintegration system including a data service device according to anembodiment of the present disclosure.

FIGS. 6 to 8 are diagrams illustrating VDM Path according to anembodiment of the present disclosure.

FIG. 9 is a diagram illustrating a process of registration andauthentication of a developed third-party service in a vessel dataintegration system according to an embodiment of the present disclosure.

FIG. 10 is a processing diagram illustrating a vessel data servicemethod in a vessel data integration system according to an embodiment ofthe present disclosure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In describing the embodiments of the specification, when a certaindetailed description of relevant known elements or functions is deemedto render the subject matter of the present specification vague, thedetailed description may be omitted herein.

The terms “comprises” and “comprising” as used herein specify thepresence of stated functions, operations and elements, but do notpreclude the presence or addition of one or more other functions,operations and elements. Additionally, it should be understood that theterm “comprises” or “includes” when used in this specification specifiesthe presence of stated features, figures, steps, operation, elements,components or groups thereof, but does not preclude the presence oraddition of one or more other features, figures, steps, operation,elements, components or groups thereof. As used herein, the singularforms are intended to include the plural forms as well, unless thecontext clearly indicates otherwise.

The key terms as used herein are defined as follows.

Vessel data integration platform (VDIP) is for collecting, processing,analyzing, storing and transmitting various vessel data, and refers toany system including software, firmware and hardware devices that managevessel data in an integrated manner or their selective combinations, ormay be used in software sense.

In an embodiment of the present disclosure, VDIP and a vessel dataintegration system may be used in the equivalent sense.

Vessel data model (VDM) is a data model for defining all data associatedwith the vessel into one system, and objectifies all devices rangingfrom the vessel itself to an end sensor and defines a relationshipbetween objects and attributes of objects.

Vessel data model configuration description Language (VCL) is thelanguage used to write a vessel data model configuration descriptionfile for describing VDM.

Vessel data model configuration description file is a configuration filethat describes VDM in VCL.

Mapping configuration description file is a file that defines a rule forconverting equipment output data into VDM based integrated vessel data.

Mapping is a process of connecting equipment output data to VDM.

Equipment is mounted in the vessel for special purposes, and collectsvarious types of vessel data generated in the vessel and transmits thecollected vessel data to VDIP. Equipment may be divided into firstequipment with a vessel data conversion device mounted thereon, andsecond equipment with no vessel data conversion device.

The first equipment is where a vessel data conversion device is directlymounted, and extracts Key that can identify vessel data and Value thatis the content of vessel data by parsing the collected vessel data invarious formats, converts the extracted Key and Value (Key:Value) into aVDM based integrated vessel data format (VDM Path:Value) through thevessel data conversion device, and transmits the converted integratedvessel data to VDIP.

Additionally, the Key-Value is related with the data representationformat, and Name-Value, Field-Value or Attribute-Value may be applied asa similar representation method. Accordingly, instead of Key, Name,Field or Attribute may be extracted.

The second equipment converts vessel data collected in various formatsinto a standardized format (e.g., National Marine ElectronicsAssociation (NMEA) format), and transmits it to VDIP using the UserDatagram Protocol (UDP) or in the form of a file.

The first vessel data conversion device converts first vessel data in“Key:Value” format outputted from the first equipment into a VDM basedintegrated vessel data format (VDM Path:Value) through a mappingoperation and transmits it to VDIP.

The second vessel data conversion device extracts Key and Value byparsing second vessel data received from the second equipment, andconverts the extracted Key and Value (Key:Value) into a VDM basedintegrated vessel data format (VDM Path:Value) through a mappingoperation.

Raw data is data in various formats collected by equipment from sensorsor devices.

Equipment output data is data in a particular format transmitted fromequipment to the vessel data conversion device, and data outputted fromthe first equipment may be in Key and Value (Key:Value) format, and dataoutputted from the second equipment may be in a standardized format(e.g., NMEA format).

Hereinafter, the embodiments of the present disclosure will be describedin detail with reference to the accompanying drawings.

First, to realize the embodiments of the present disclosure, a VesselData Model (VDM) is established to manage all formats of data generatedin the vessel into one system.

VDM largely has three conceptual categories, and the three concepts arevessel data standardization principle (Principle), Language and CommonData Structure.

To represent vessel data, VDM defines a combination of three models,Vessel Model of modeling Vessel Part, System Model of modeling SystemPart, and Data Model of modeling Data Type Part as shown in FIG. 2.

The vessel model is a hierarchical classification system of equipmentthat constitutes the vessel, and is an entire set of equipment that canbe defined for each level, and the entire set can be extended.

As shown in Table 1, the vessel model may be defined as four levels.

TABLE 1 Level Name Description Remarks Level 1 Vessel Vessel. Top-levelelement Level 2 Equipment Group Conceptual group of equipment Level 3Equipment Real equipment or abstract/logical equipment Level 4 ComponentSubdivision of Equipment optional

As shown in FIG. 2, Vessel has one or more Equipment Groups, eachEquipment Group has 0 or more Equipment, and each Equipment has 0 ormore Component.

Here, the highest level, Level 1, is Vessel that signifies the vesselitself. Vessel includes an IMO number corresponding to a unique ID thatidentifies the vessel.

Instances of Level 2, Equipment Group level, make up one Vessel. Here,Equipment Group is subordinate to Vessel.

Level 2, Equipment Group, is a conceptual group of Level 3, Equipment,and may use the group name widely used for classification in theshipbuilding industry. For example, classification into Machinery, Hull,Electrical, and Navigational may be used.

Level 3, Equipment, is a level that mainly represents real equipment,and has the largest number of available items and instances in realequipment.

The Equipment level is not limited to only real equipment, and mayrepresent abstract or logical equipment. For example, not only realphysical equipment such as engines or boilers, but also abstract/logicalconcept such as stability indication and loading status may be applied.

Level 4, Component, is an optional level used when subdividing Equipmentinto smaller parts, and is used when classification and reuse is neededdue to independency of Component itself or when the scale of Equipmentitself is large. For example, in the case of the engine, many cylinders,auxiliary machines and piping systems form a huge integrated system, sowhen each is subdivided into components and defined, making it possibleto classify under necessary viewpoints and separately use.

The entire vessel model set described above can be continuouslyextended.

Meanwhile, the system model is a structured logical model for datagenerated from the equipment that constitutes the vessel.

Mechanical, electrical, hydraulic, pneumatic, electronic, communicationor software (S/W) equipment exists together in the vessel, and datagenerated from the equipment is collected by devices (InformationTechnology (IT), electronic and S/W equipment) capable of collectingdata.

The system model is used to define an internal data model for data thatcan be collected in the individual data collection devices (equipment).

The system model increases the reusability of the data model and managesthe variability in the data collection device. For example, the datacollection device, equipment A, is a device that collects data relatedto the engine and the piping system, the device's own logical model forthe engine and the piping system may be established in the device.Additionally, when the data collection device, equipment B, is a devicethat mainly collects data related to navigation, a logical model mainlyabout navigation data will be established. In case that equipment Bneeds to collect some of the data of equipment A in the future, it ispossible to reuse the model in such a way that equipment B may importand use the logical model of equipment A.

As shown in Table 2, the system model may be defined as four levels.

TABLE 2 Level Name Description Remarks Level 1 System System Level 2Logical Device Top-level logical equipment modeling Level 3 Logical NodeBasic unit of logical function Level 4 Data Object Instance of data type

System has one or more Logical Devices, each Logical Device has one ormore Logical Nodes, and each Logical Node has one or more Data Objects.

Level 1, System level, represents a data collection device (equipment),and includes one or multiple logical devices.

Level 2, Logical Device level, is the highest-level concept of logicalequipment modeling, and includes one or multiple logical nodes.

Logical Device may include, for example, models of main engine,generator engine, boiler, tank and positioning device defined in System,and may be a model of concept of their combination.

Level 3, Logical Node level, includes objects that are created bymodeling the function units of the vessel domain, and is the mostfundamental level of VDM. Logical Node may include the following threeelements.

-   -   Prefix: prefix (optional) that defines Logical Node according to        the purpose or use of Logical Node    -   Class: indicates the type or category of Logical Node    -   Inst: number necessary when indicating multiple objects

The Logical Node name (LNName) of is defined as <prefix>+<class>+<inst>,and this combination should be unique within a logical device to whichthe corresponding logical node belongs. For example, three pumps used inCentral CFW system may be modeled using a predefined Pump Class, andeach may be referred to as CentralCFWPump1, CentralCFWPump2 andCentralCFWPump3 so that they can be distinguished from other pumps usingthe prefix CentralCFW. If there is no overlap, CentralCFW may beomitted, and each may be defined as Pump1, Pump2 and Pump3.

Class of Logical Node is the key element of standardization thatencourages to predefine and use the objects of the essential functionunits of the vessel domain.

Level 4, Data Object level, is the most basic unit of dataconfiguration, and objectifies and defines Data Class of Data Model.

Meanwhile, the data model provides the means for creating a desired dataobject by providing a method that can define not only a basic data type,but also their combination, or a composite data type.

When the system model is a structured logical model for data generatedfrom equipment that constitutes the vessel, the data model is a modelthat represents the generated data itself, and the data type may bedefined by recursive structurization. The data model increases thereusability of the data type and manages the variability.

This data model may include the following elements.

-   -   Data Class    -   Data Attribute    -   Recursion of Data Attribute (optional)    -   Basic Data Type

Data Object of the system model assigns an ID to objectify and defineData Class of the data model.

Data Class is a data type in which data attributes are grouped into ameaningful combination.

Data Attribute is the most basic unit of the data model and can berecursively defined, and finally, has one of basic data types (Float,Timestamp, String, . . . ) as a type.

As described above, VDM includes a vessel model, a system model and adata model, and these three models are combined to form a VDM.

The basic principle of a combination model that combines the threemodels described above is as follows.

-   -   Vessel model systematically classifies and hierarchically        divides the vessel.    -   System model defines a logical node of logical equipment in a        particular system.    -   Data model defines data class of data object of system model.    -   Instance of equipment or component level of vessel model may be        connected with logical node of system model.    -   Connection information for connecting vessel model with logical        node of system model may be set.    -   Connection information indicates system and logical device for        connection of an only logical node.    -   Data object of system model objectifies data class of data        model.

Each instance (object) defined by VDM as noted above is assigned with anobject identifier for uniquely identifying each instance (object), anddata attribute is defined.

VDM refers to the object identifier as VDM Path. That is, the VDM Pathis used as a unique identifier for particular data in the vessel.Additionally, the VDM Path may be used as a routing rule for indicatingparticular vessel data on VDM.

For example, the rule of the VDM Path is as follows.

<VDM Path>=<Equipment Group Name>/<Equipment Name>/<ComponentName>/<Logical Device Name>/<Logical Node Name>.<Data ObjectName>.[<Data Attribute Name>]+

Here, <Logical Node Name> is composed of <prefix>+<class>+<inst>, and +following [<Data Attribute Name>] represents one or more repetitions.

Vessel Model System Model Data Model Equipment Equipment ComponentLogical Logical Node Name Data Data Group Name Name Device Prefix ClassInstance Object Attribute Name Name Name Name

The VDM Path of this rule may or may not include the prefix of equipmentand component of the vessel model and logical device and logical node ofthe system model if necessary.

The data attribute defines attributes that data of a correspondinginstance should have.

As described above, vessel data summarized by VDM should be described inthe form that can be understood by both the system and the interestparties, and to this end, VCL is defined.

VCL is the language used to write a vessel data model configurationdescription file for describing VDM, and VCL is not limited to aparticular type and may use all languages satisfying the followingspecification as VCL.

-   -   It is possible to describe all elements of vessel model, system        model, data model.    -   It is possible to set the values of attributes that each element        has, and extend the attributes.    -   It is possible to describe the combination model.

In an embodiment of the present disclosure, it is possible to write avessel data model configuration description file (e.g., VDMConfiguration XML) based on VCL using XML (eXtensible Markup Language)Schema Definition (XSD) as VCL satisfying the above-describedspecification.

The vessel data model configuration description file is a configurationfile that describes VDM in VCL, and includes the definition of VesselPart, System Part and Data Type Part.

Accordingly, it is possible to extract VDM from a vessel data modelconfiguration description file that describes VDM in VCL, and extractVDM Path and data attributes from the extracted VDM.

Hereinafter, the vessel data integration platform (VDIP) for managing(collecting, storing, providing) vessel data in various formats made bydifferent protocols in an integrated manner based on VDM will bedescribed.

FIG. 3 is a schematic diagram showing the configuration of a smart shipwith the vessel data integration platform according to an embodiment ofthe present disclosure.

In FIG. 3, VDIP performs collection of various types of data in thevessel into a standardized system, processing and analysis, storage,onshore transmission and other onboard S/W data service.

Onshore service platform receives data transmitted from the vessel andstores it on the shore, and provides an overall service based on it.

Bigdata platform extracts and analyzes value of data by data analysis ofnavigation information stored on the shore if necessary.

FIG. 4 is a schematic diagram showing the main functions of the vesseldata integration platform according to an embodiment of the presentdisclosure.

VDIP converts vessel data (raw data) collected from IT equipment ordevices, such as alarm data, sensor data and configuration data, into asystematized format based on VDM.

Additionally, the VDM based integrated vessel data converted into asystematized format is transmitted to an onshore management system, orprovided to a third-party service.

Here, the onshore management system may be a concept corresponding tothe onshore service platform of FIG. 3.

Among vessel data collected from IT equipment or devices as describedabove, sensor data is a real value generated from the sensor installedin the vessel, alarm data is a value representing various type ofwarning signals generated in the vessel, and configuration data isconfiguration information for each sensor, for example, the unit (e.g.,m, cm, ° C., °, etc.) of the numerical value used in sensor data and theminimum value (Min)/maximum value (Max) of the numeric value.

FIG. 5 is a schematic diagram showing the configuration of the vesseldata integration system including a data service device according to anembodiment of the present disclosure.

In FIG. 5, equipment 10 is mounted in the vessel for special purposes,and collects various types of vessel data (raw data) generated indifferent formats within the vessel, i.e., alarm data, sensor data andconfiguration data. Additionally, the equipment 10 transmits thecollected vessel data (raw data) to the vessel data integration system100.

That is, the VDIP 100 collects vessel data through at least oneequipment (e.g., AMS, INS, a loading computer, VDR, etc.) 10. As such,the VDIP 100 may directly collect vessel data, but may use the existingvessel equipment 10 as a gateway for data collection.

Here, vessel data generated in the vessel may cover various typesincluding text, audio, image, video, etc.

The equipment 10 may be divided into first equipment 11 with a firstvessel data conversion device 110 mounted thereon, and second equipment13 with no first vessel data conversion device 110.

The first equipment 11 is where the first vessel data conversion device110 is directly mounted, and collects vessel data in various formatsfrom at least one sensor or device, and extracts Key and Value(Key:Value) by parsing the collected vessel data in various formats.Additionally, the first equipment 11 converts first vessel data in anon-standardized format, Key and Value (Key:Value), into a VDM basedintegrated vessel data format (VDM Path:Value) through the first vesseldata conversion device 110, and transmits the converted integratedvessel data to the vessel data integration system 100.

That is, the first vessel data conversion device 110 converts the firstvessel data in a non-standardized format, Key and Value (Key:Value),into an integrated vessel data format (VDM Path:Value), by replacing Keyreceived from the first equipment 11 with VDM Path assigned based onVDM. Here, a connection operation for replacing Key extracted from rawdata with VDM Path assigned based on VDM is a “mapping” operation, andthrough the mapping operation, the extracted Key is connected to the VDMPath to convert validity verified Value into an integrated vessel dataformat (VDM Path:Value).

When converting Key and Value (Key:Value) into a VDM based integratedvessel data format (VDM Path:Value) by replacing Key with VDM Path, itis necessary to verify the validity of Value of Key according toattribute of Data Attribute.

Data Attribute is attribute information of vessel data, and definesattributes that Value of vessel data should have. Accordingly, thevalidity of Value of Key extracted from raw data is verified accordingto attribute defined in Data Attribute corresponding to thecorresponding vessel equipment.

The first equipment 11 may include an Alarm Monitoring System (AMS), anIntegrated Navigation System (INS) and a loading computer.

The second equipment 13 converts vessel data collected in variousformats into second vessel data in a standardized format (e.g., NMEAformat), and transmits it to the vessel data integration system 100using the UDP or in the form of a file.

The second equipment 13 may include a Voyage Data Recorder (VDR).

The first vessel data conversion device 110 is mounted in the firstequipment 11, and converts validity verified Value into an integratedvessel data format (VDM Path:Value) by connecting Key in first vesseldata in a non-standardized format outputted from the first equipment 11,i.e., vessel data in Key:Value format to VDM Path through a mappingoperation.

The first vessel data conversion device 110 described above may beimplemented as a program and installed on the first equipment 11.

The first vessel data conversion device 110 described above may bereferred to as Agent.

The second vessel data conversion device 120 receives the second vesseldata in a standardized format (e.g., NMEA format) from the secondequipment 13 using the UDP or in the form of a file.

Additionally, the second vessel data conversion device 120 extracts Keyand Value (Key:Value) by parsing the second vessel data received fromthe second equipment 13, and converts the extracted Key and Value(Key:Value) into a VDM based integrated vessel data format (VDMPath:Value) through a mapping operation.

The second vessel data conversion device 120 described above may bereferred to as Adapter.

The integrated vessel data converted from the first vessel dataconversion device 110 and the second vessel data conversion device 120described above may be represented in JavaScript Object Notation (JSON)format.

When a data processing unit 130 receives the integrated vessel data fromthe first vessel data conversion device 110 or the second vessel dataconversion device 120, the data processing unit 130 transmits thereceived integrated vessel data to Complex Event Processing (CEP) 150based on tag information of the received integrated vessel data when thereceived data is data that is to be transmitted in real time like alarmdata. Additionally, when the received data is data (e.g., sensor data,configuration data) that does not need to be transmitted in real time,the data processing unit 130 stores the received integrated vessel datain a storage DB 170.

The data processing unit 130 described above receives the integratedvessel data transmitted by the first vessel data conversion device 110using a message queue.

A rule engine 140 manages a data validity validation rule necessary toverify the validity of the integrated vessel data received from thefirst vessel data conversion device 110 or the second vessel dataconversion device 120. For example, the rule engine 140 may manage theminimum value (Min) and the maximum value (Max) for each sensor toverify the validity of sensor data.

Additionally, the rule engine 140 stores the integrated vessel datareceived from the first vessel data conversion device 110 or the secondvessel data conversion device 120 in a corresponding DB provided in thestorage DB 170. That is, sensor data is stored in a sensor data DB 171,alarm data is stored in an alarm data DB 173, and configuration data isstored in a configuration data DB 175.

The CEP 150 transmits data (e.g., alarm data) that is to be immediatelytransmission processed in real time among the integrated vessel datareceived from the data processing unit 130, in real time via satellitecommunication through an onshore communication unit 160.

Here, the communication protocol used for data transmission usingsatellite communication may include Message Queueing Telemetry Transport(MQTT), Constrained Application Protocol (CoAP), Mail, File TransferProtocol (FTP), Simple Control Protocol (SCP), HyperText TransferProtocol (HTTP), etc. Preferably, Internet of Things (IoT) applicationprotocol, MQTT, may be used.

Satellite communication services that can be used for data transmissionmay include 1) Fixed Satellite Service (FSS), 2) Mobile SatelliteService (MSS) and 3) Broadcast Satellite Service (BSS) according to thepurpose of use, and may include 4) international satellite service(INTELSAT, INMARSAT), 5) regional satellite service (EUTELSAT, PANAMSAT)and 6) domestic satellite service (KORESAT, BS) according to the area.Additionally, Very Small Aperture Terminal (VSAT) that is a satellitecommunication service provided using small-diameter antennas and onshoreequipment with low transmit output may be used. Preferably, Inmarsat FB(FleetBroadband), Inmarsat Global Express (Xpress) or Fleet Xpress maybe used.

Additionally, data transmission by the onshore communication unit 160may be performed through wireless communication protocols other thansatellite communication. For example, Wireless LAN (WLAN), Wi-Fi,Wireless broadband (Wibro), World Interoperability for Microwave Access(Wimax), or general mobile communication methods such as High SpeedDownlink Packet Access (HSDPA), 3^(rd) Generation (3G), Long TermEvolution (LTE), Long Term Evolution-Advanced (LTE-A), etc. may be used.Particularly, when the vessel including the vessel data integrationsystem 100 is near or along the shore or close to the onshore managementsystem 200, data transmission may be performed after changing towireless communication, not satellite communication.

The onshore communication unit 160 is responsible for data transmissionand reception between the vessel data integration system 100 and theonshore management system 200.

A real-time data transmission unit 161 of the onshore communication unit160 is responsible for transmission processing of data (e.g., alarmdata) that needs to be transmitted in real time.

A batch data transmission unit 163 is responsible for transmissionprocessing of data stored in the storage DB 170 in a periodic time unit.

A remote data search unit 165 is responsible for searching for(retrieving) the corresponding vessel data in the storage DB 170 andtransmitting it in response to a vessel data request from the shore.

The storage DB 170 stores and manages the integrated vessel data, andincludes the sensor data DB 171 to store sensor data, the alarm data DB173 to store alarm data, the configuration data DB 175 to storeconfiguration data, and a vessel data DB 177 to store metadata anddesign data.

The above-described storage DB 170 stores the collected integratedvessel data for a predetermined period of time (e.g., 30 days) to allowhistory tracking on the shore and prevent data losses caused by networkdisconnection.

The vessel data stored in the above-described storage DB 170 ispreferably stored according to the VDM system.

Additionally, the storage DB 170 may be implemented as MongoDB of Notonly SQL (Structured Query Language) (NoSQL) to provide flexibility ofdata management.

A data service device 180 searches for (retrieves) data that a servicerequester 300 needs, in the storage DB 170, and provides it. The servicerequester 300 may specify and search for desired data using VDM Pathbased on VDM.

When the service requester 300 requests data using VDM Path, the dataservice device 180 may first identify if the service requester 300 hasan access authority for the VDM Path based data range requested from theservice requester 300, and as a result of identification, only when theservice requester 300 has the access authority, the data service device180 may search for the corresponding data and provide the search resultto the service requester 300.

The data search method largely includes Query method and Push method.

The data service device 180 provides a data service ApplicationProgramming Interface (API) (Query API, Push API) to collect data thatthe service requester 300 needs.

The vessel data integration system configured as noted above collectsvessel data in various formats made by different protocols, convert itinto a systematic integrated vessel data format based on VDM, andprovides the converted integrated vessel data to the onshore managementsystem 200 or the service requester 300.

The data service device 180 described above includes a communicationunit 181 and a search unit 182, and according to embodiments, mayfurther include an identification unit 183 and a management unit 184.

The communication unit 181 is responsible for data transmission andreception with the service requester 300, and receives a vessel datarequest including VDM Path from the service requester 300, transmits itto the search unit 182, and in response to the vessel data request,receives the corresponding data retrieved from the search unit 182 andtransmits it to the service requester 300.

The search unit 182 identifies, by the received VDM Path, vessel datadesired by the service requester 300, searches for the correspondingdata from the storage DB 170 in which vessel data is stored, andprovides it to the service requester 300 through the communication unit181.

The VDM Path hierarchically defines paths leading to each vessel data onVDM, and is used to identify each vessel data.

Here, the VDM Path used for vessel data search may be “VDM Path forservice data provision” as described below in FIGS. 6 to 8.

The range of data searched by the search unit 182 may hierarchicallychange depending on the hierarchy level of the VDM Path.

The search unit 182 described above may include a first search unit182_1 and a second search unit 182_2.

When the service requester 300 transmits the vessel data request usingPush API, the first search unit 182_1 receives VDM Path based vesseldata by Push method from the storage DB 170 and transmits it to theservice requester 300.

When the service requester 300 transmits the vessel data request usingQuery API, the first search unit 182 extracts VDM Path based vessel databy Pull method from the storage DB 170 and provides it to the servicerequester 300.

The identification unit 183 identifies, based on the VDM Path, if theservice requester 300 has an access authority for the data rangespecified by the VDM Path (e.g., an access authority for a particularlayer or level defined by the VDM Path), and determines whether toapprove the search.

When as a result of identification by the identification unit 183, theservice requester 300 has the data access authority, the search unit 182searches for the corresponding data and provides the search result tothe service requester 300.

The management unit 184 supports registration and authentication of theservice requester 300 to allow the service requester 300 to search fornecessary vessel data in the storage DB 170 of the VDIP 100.

The service requester 300 described above is the means of providingvarious services (safe navigation, economical sailing, collisionavoidance, engine monitoring, other additional/applied service, etc.)using vessel data, and may be referred to as other onboard S/W dataservice and a third-party service, and implemented in the form ofsoftware, mobile application (app), firmware or hardware, or theircombinations.

For example, when the service requester 300 is implemented in the formof a mobile application (app) mounted on smart equipment, the servicerequester 300 may specify desired vessel data using VDM Path on thescreen of the corresponding application, conduct a search, receive thecorresponding data from the VDIP 100 and use it for a desired service.

Hereinafter, the process of managing (collecting, storing, providing)vessel data in various formats made by different protocols into a VDMbased integrated vessel data format will be descried in more detail.

The VDM Path is used as an identifier that is unique to particular datain the vessel as previously described, and is also used as a routingrule for indicating particular vessel data on VDM.

Accordingly, in transmitting and receiving vessel data based on VDM,VDIP may identify each vessel data according to the VDM Path.

As shown in FIG. 6, the VDM Path may be divided into “VDM Path forequipment data collection” and “VDM Path for service data provision”.

The “VDM Path for equipment data collection” reflects the levels ofSystem Part and Data Type part as shown in FIG. 7.

The structure system of the “VDM Path for equipment data collection” isas follows (see FIG. 7).

<System Name>/<Logical Device Name>/<Logical Node Name>.<Data ObjectName>.[<Data Attribute Name>]+

Here, <Logical Node Name> is composed of <prefix>+<class>+<inst>, and +represents one or more repetitions.

The “VDM Path for equipment data collection” of the structure systemdescribed above may or may not include the prefix of System, LogicalDevice and Logical Node of System Part level if necessary.

Additionally, the “VDM Path for equipment data collection” may reflectall the levels of Vessel Part, System Part and Data Type Part.

In this case, the structure system of the “VDM Path for equipment datacollection” is as follows.

<Equipment Group Name>/<Equipment Name>/<Component Name>/<Logical DeviceName>/<Logical Node Name>.<Data Object Name>.[<Data Attribute Name>]+

Here, <Logical Node Name> is composed of <prefix>+<class>+<inst>, and +represents one or more repetitions.

The “VDM Path for equipment data collection” of the structure systemdescribed above may or may not include the prefix of Equipment andComponent of Vessel Part level and Logical Device and Logical Node ofSystem Part level if necessary.

Meanwhile, the “VDM Path for service data provision” reflects the levelsof Vessel Part, System Part and Data Type Part.

The structure system of the “VDM Path for service data provision” is asfollows (see FIG. 8).

<Equipment Group Name>/<Equipment Name>/<Component Name>/<Logical DeviceName>/<Logical Node Name>.<Data Object Name>.[<Data Attribute Name>]+

Here, <Logical Node Name> is composed of <prefix>+<class>+<inst>, and +represents one or more repetitions.

The “VDM Path for service data provision” of the structure systemdescribed above may or may not include the prefix of Equipment andComponent of Vessel Part level and Logical Device and Logical Node ofSystem Part level if necessary.

As shown in FIG. 8, the range of data provided may hierarchically changedepending on the hierarchy level of the VDM Path used for service dataprovision.

For example, when an input of ‘Machinery/Machinery equipment/Dieselengine’ as VDM Path is received from a 3^(rd) party service, allinformation associated with diesel engine is provided to the 3^(rd)party service, and when an input of ‘Machinery/Machineryequipment/Diesel engine/Pump1’ as VDM Path is received from a 3^(rd)party service, information associated with pump1 in the diesel engine isprovided to the 3rd party service.

Additionally, it is possible to manage a set of necessary VDM Paths toprovide a particular customized service to a 3^(rd) party service.

When providing vessel data for an onshore service, a unique ID foridentifying the vessel, vessel IMO number (e.g., 1111111), is added infront of the VDM Path.

FIG. 9 is a diagram illustrating a process of registration andauthentication of a developed third-party service in the vessel dataintegration system according to an embodiment of the present disclosure.

Vessel data collected/stored by VDIP through Agent or Adapter may beused in a third-party service (S/W).

The third-party service may search for (retrieve) necessary vessel datain VDIP, and for the third-party service to search for vessel datacollected by VDIP and make use of it, the corresponding third-partyservice should be registered and authenticated in VDIP.

The process of registration and authentication of a developedthird-party service in VDIP is as shown in FIG. 9.

First, (1) a third-party service developer accesses a developer supportsite, signs up, logs in, and downloads a kit necessary for third-partyservice development.

The kit includes VDIP emulator Virtual Machine (VM) to execute VDIP indevelopment environment.

The VDIP emulator VM can be accessed through Secure Shell (SSH) and WebConsole, and gets access through Secure Shell and performs the controlof respective components of VDIP and VM termination, and performs theVDIP function control and main information monitoring function throughWeb Console.

The third-party service developer develops a third-party service bygenerating virtual vessel data through the VDIP emulator.

The VDIP emulator provides a test application account that allows freesearch of (retrieval) all data without registration as follows.

-   -   App Alias    -   Certificate: Private Key that will be used in a test        application, Certificate and CA certificate    -   DPL: Signed DPL that allows for search (retrieval) of all data    -   Data service API access information

(2) The third-party service developer develops a third-party serviceusing the VDIP emulator running on the VDIP emulator VM and sample datagenerated by the VDIP emulator. In this instance, the range of targetdata for search (retrieval) is determined through a data service APIprovided by the VDIP. The range of target data for search (retrieval)may be determined by VDM Path. The VDIP may limit the searchable datarange for each third-party service for security reasons.

(3) The third-party service developer requests a registration process ofthe developed third-party service and Certificate, by submitting, to thedeveloper support site, an execution file of the developed third-partyservice, X.509 Certificate Signing Request (CSR) and Data PermissionList (DPL) of data desired to receive at VDIP. The submission method mayinclude sending via e-mail, and it is necessary to send the name of thethird-party service (Application Name) together.

As the above-described CRS includes Private Key that will be used in thedeveloped third-party service, a care should be taken to prevent thePrivate Key from being deleted.

If Certificate was issued using CSR, but there is no Private Key, thethird-party service registration operation should be performed again.

DPL is a file that specifies the data range that each third-partyservice can use, and this is for preventing excessive data access(search, retrieval) authority, thereby increasing the system stability,and reducing the security risk, and after investigation of authorityrequested from a developer support site manager in the third-partyservice registration process, when there is no problem, the third-partyservice registration is approved. Here, the data range that thethird-party service can use is defined using VDM Path.

(4) The developer support site having received the third-party serviceexecution file, CRS and DPL from the third-party service developerpermits the corresponding third-party service to be installed in VDIP byregistering the corresponding third-party service when there is noproblem after investigation of the third-party service execution file,CRS and DPL. Additionally, Certificate (third-party service certificate)for CSR, topmost CA certificate and Signed DPL (encrypted version of DPLsubmitted by the third-party service developer to prevent forgery andfalsification) are provided to the third-party service developer. Thecertificate issuance may be performed through an e-mail, and App Aliascorresponding to the unique ID of the third-party service may be issuedand transmitted together.

(5) Subsequently, the developer support site transmits a list ofauthenticated third-party services (App Aliases) to VDIP and stores itas a white list of installable third-party services. Accordingly, whenthe third-party service is installed in the vessel and gets access(third-party service registration request), VDIP may determine whetherto permit by identifying if the third-party service is present in thewhite list.

(6) The third-party service developer adds authentication informationreceived from the developer support site, i.e., Certificate (third-partyservice certificate), topmost CA certificate and Signed DPL, to thethird-party service.

(7) Vessel manager installs the third-party service in the vessel, andinputs VDIP information (as VDIP runs in different environments for eachvessel, IPs may be different).

When VDIP information is inputted into the third-party service installedin the vessel, the third-party service calls the data service API (e.g.,third-party service registration API) to register itself in VDIP. Here,when the third-party service calls the data service API (e.g.,third-party service registration API) for registering itself in VDIP,the third-party service needs to submit App Alias, Certificate andSigned DPL.

(8) VDIP identifies if the third-party service having requestedregistration after being installed in the vessel is included in the listof installable third-party services (white list), and when included,registers information associated with the corresponding third-partyservice in VDIP.

(9) Subsequently, VDIP provides the third-party service havingsucceeding in registration with authentication information (username,password, cunsumerKey, consumerSecret) necessary to call the dataservice API (Query API, Push API).

After the third-party service is installed in the vessel for the firsttime, the third-party service should request registration to VDIP onlyonce, and thus it is desirable to continuously store the receivedauthentication information, rather than removing it, and re-use at thetime of next execution. Accordingly, when registering the third-partyservice, the VDIP investigates if authentication information is presentin the third-party service having requested registration, and whenpresent, regards the corresponding third-party service as being alreadyregistered, and when absent, performs a new registration process.

(10) The third-party service calls the data service API (e.g., QueryAPI) for data search using the stored authentication information.

When the third-party service is registered, in case that the third-partyservice runs again, the stored authentication information is useddirectly without passing through the above-described processes of (7) to(9).

Data search (retrieval) can be conducted by specifying and searching fordesired data through the grammar of VDM Path based on VDM.

Data search is divided into Query method and Push method, and targetdata for search includes sensor data, alarm data and configuration data.

(11) VDIP identifies if the VDM Path based data range requested from thethird-party service is included in the DPL submitted in (3) thethird-party service registration process.

As a result of identification, when the VDM Path based data rangerequested from the third-party service is not included in the DPL, anapproval error occurs.

(12) As a result of identification, when the third-party service has thedata access authority, the VDIP searches for the corresponding data andprovides the search result to the third-party service.

The VDIP according to an embodiment of the present disclosure providesthe following data service APIs to collect data that the third-partyservice needs.

-   -   Third-party service registration API: API necessary to register        the third-party service in VDIP for the first time    -   Query API: API for searching for desired data by Pull method        based on VDM Path    -   Push API: API for receiving desired data from VDIP by Push        method

Among the above-described APIs, other APIs except the third-partyservice registration API need authentication information.

The Query API is an API for collecting sensor, alarm and configurationdata by Pull method, and may include API (latestQuery) for searchinglatest data, API (periodArrayQuery) for searching data by array type,API (periodJsonQuery) for searching for data by Json type, API(periodXMLQuery) for searching data by XML type, API (periodAllQuery)for searching data included in a preset period of time, API(binaryQuery) for searching binary data, for example, a radar image andaudio records, API (getStructuredPath) for searching the structure ofthe VDM Path, API (datasetQuery) for searching datasets, API(createDataset) for generating a new dataset, and API (configDataQuery)for searching latest configuration data.

When calling the above-described Query API, VDIP information may be usedas a URL prefix.

Meanwhile, collection of sensor and alarm data by Push method isperformed by registering an event rule to enable CEP to process sensorand alarm data, loading the sensor and alarm data processed by CEPaccording to the event rule to the same queue as the event rule name,and collecting the sensor and alarm data loaded to the queue in realtime.

Additionally, Push client accesses Push server while includingauthentication information of the data service API, and is then used toreceive real-time data of sensor and alarm processed by CEP.

To use the above-described Push client, a third-party service dedicatedevent rule should be registered in CEP in advance.

As described above, the event rule for processing sensor and alarm datashould be registered in CEP, and API about registration and deletion ofthe event rule are as follows.

-   -   CEP event rule registration API for sensor data: register an        event rule used to process sensor data in CEP    -   CEP event rule deletion API for sensor data: delete an event        rule for sensor data registered in CEP    -   Sensor data search API: search single sensor data processed by        CEP    -   CEP event rule registration API for alarm data: register an        event rule used to process alarm data in CEP    -   CEP event rule deletion API for alarm data: delete an event rule        for alarm data registered in CEP    -   Alarm data search API: search single alarm data processed by CEP    -   Number search API: search the number of sensor data or alarm        data loaded to queue

When calling the above-described Push API, URL context indicating IPinformation of VDIP and the API type may be used.

These APIs are preferably implemented in the form of open API.

FIG. 10 is a processing diagram illustrating a vessel data servicemethod in the vessel data integration system according to an embodimentof the present disclosure.

First, the data service device 180 receives a vessel data requestincluding VDM Path from the service requester 300 (S110).

Subsequently, vessel data requested from the service requester 300 isidentified using the VDM Path received through the above-described stepS110, and the corresponding vessel data is searched for from the storageDB 170 in which vessel data is stored (S150).

As described above, the VDM Path hierarchically defines paths leading toeach vessel data on VDM, and is used to identify each vessel data.

The VDM may include a vessel model, a system model and a data model.Here, the vessel model defines the hierarchical structure in the orderof vessel, equipment group, equipment and component. The system modeldefines the hierarchical structure in the order of system, logicaldevice and logical node for collecting vessel data. The data modeldefines the hierarchical structure in the order of data object about thestructure of vessel data, and data attribute about attribute of vesseldata.

The range of data that is searched for in the above-described step S150may hierarchically change depending on the hierarchy level of the VDMPath.

The vessel data found in the above-described step S150 may be providedto the service requester 300 in response to the vessel data requestreceived in the above-described step S110 (S160).

The data search method in the above-described step S150 largely includesQuery method and Push method.

When the service requester 300 transmits the vessel data request of S110using Query API, the data service device 180 extracts VDM Path basedvessel data from the storage DB 170 by Pull method and transmits it tothe service requester 300.

When the service requester 300 transmits the vessel data request of S110using Push API, the data service device 180 receives VDM Path basedvessel data from the storage DB 170 by Push method and transmits it tothe service requester 300.

Before performing the search operation in the above-described step S150,the data service device 180 identifies if the corresponding servicerequester 300 has an access authority for the data range specified bythe VDM Path of S110 (S120) first, and determines whether to approve thesearch (S130).

As a result of identification in the above-described step S120, when theservice requester 300 has a data access authority, the search for theVDM Path based data range requested from the service requester 300 isapproved (S130), search for the corresponding data is conducted (S150),and the search result is provided to the service requester 300 (S160).

As a result of identification in the above-described step S120, when theservice requester 300 does not have a data access authority, forexample, when vessel data desired by the service requester 300 isoutside the data range that can be accessed by the VDM Path received inS110, an approval error is generated (S130, S140).

Those having ordinary skill in the technical field pertaining to thepresent disclosure will appreciate that various modifications andchanges may be made without departing from the essential nature of thepresent disclosure. Additionally, the embodiments disclosed in thespecification and drawings are only a particular embodiment presented toeasily describe the disclosure and help the understanding of the presentdisclosure, but not intended to limit the scope of the presentdisclosure. Therefore, it should be interpreted that the scope of thepresent disclosure cover the embodiments disclosed herein as well as allmodified or changed forms derived based on the technical spirit of thepresent disclosure.

INDUSTRIAL APPLICABILITY

According to the vessel data integration system of the presentdisclosure and the vessel comprising the same, necessary vessel data maybe efficiently provided to various third-party services.

1. A data service method in a vessel data integration system,comprising: receiving a vessel data request including a Vessel DataModel Path (VDM Path) from a service requester; and searching for therequested vessel data from a database in which vessel data is stored,based on the VDM Path.
 2. The data service method in the vessel dataintegration system according to claim 1, wherein the VDM Pathhierarchically defines paths leading to each vessel data on a VesselData Model (VDM), and each vessel data is identified by the VDM Path. 3.The data service method in the vessel data integration system accordingto claim 1, wherein a data range in which to perform the searchhierarchically changes depending on hierarchy level of the VDM Path. 4.The data service method in the vessel data integration system accordingto claim 1, further comprising: identifying if the service requester hasan access authority for a data range specified by the VDM Path, wherein,as a result of the identification, when the service requester has theaccess authority, performing the search.
 5. The data service method inthe vessel data integration system according to claim 2, wherein the VDMis generated by combining a vessel model, a system model and a datamodel, the vessel model defines hierarchical structure in an order ofvessel, equipment group, equipment and component, the system modeldefines hierarchical structure in an order of system, logical device andlogical node for collecting vessel data, and the data model defineshierarchical structure in an order of data object about structure ofvessel data and data attribute about attribute of vessel data.
 6. Thedata service method in the vessel data integration system according toclaim 5, wherein the VDM Path includes at least one name of equipmentgroup, equipment, component, logical device, logical node, data objectand data attribute.
 7. The data service method in the vessel dataintegration system according to claim 6, wherein the VDM Path has asequential arrangement of at least one name of equipment group,equipment, component, logical device, logical node, data object and dataattribute.
 8. The data service method in the vessel data integrationsystem according to claim 1, further comprising: providing the foundvessel data to the service requester in response to the vessel datarequest.
 9. The data service method in the vessel data integrationsystem according to claim 1, wherein the searching comprises: in case ofthe vessel data request using a Query Application Programming Interface(API), extracting the requested vessel data by a Pull method, and incase of the vessel data request using a Push API, receiving therequested vessel data by a Push method.
 10. A data service device in avessel data integration system, comprising: a communication unit toreceive a vessel data request including a Vessel Data Model Path (VDMPath) from a service requester; and a search unit to search for therequested vessel data from a database in which vessel data is stored,based on the VDM Path.
 11. The data service device in the vessel dataintegration system according to claim 10, wherein the VDM Pathhierarchically defines paths leading to each vessel data on a VesselData Model (VDM), and each vessel data is identified by the VDM Path.12. The data service device in the vessel data integration systemaccording to claim 10, wherein the search unit hierarchically changes adata range in which to perform the search, depending on hierarchy levelof the VDM Path.
 13. The data service device in the vessel dataintegration system according to claim 10, further comprising: anidentification unit to identify if the service requester has an accessauthority for a data range specified by the VDM Path, wherein as aresult of the identification by the identification unit, when theservice requester has the access authority, the search unit performs thesearching operation.